从 Redux 中间件实现原理切入，理解“面向切面编程”|原理篇 | 前端进阶之旅

⚡ 30 秒速记

核心判断：状态管理的核心是把状态变化约束成可追踪的数据流，中间件在派发边界扩展异步、日志和副作用
原理主线：围绕「认识 Redux 中间件」、「Redux 中间件是如何与 Redux 」、「thunk 中间件到底做了什么？」建立输入、状态变化与输出之间的因果关系
文章范围：通过剖析 Redux 中间件的实现原理，深入讲解中间件如何扩展 Redux 的功能，支持异步 action、日志记录等场景，并结合“面向切面编程”思想，帮助读者理解前端状态管理的灵活性与可扩展性。
边界与代价：集中式状态不是越多越好；可变性、订阅粒度和异步取消决定性能与可维护性
工程落地：选型要从状态归属、更新频率、调试需求和团队约束出发，而不是只比较 API 数量

Redux 中间件本质上是在 dispatch 与 reducer 之间增加一层可组合的拦截逻辑，用来统一处理异步和其他副作用。 applyMiddleware 作为 store enhancer 接管原始 dispatch，把各中间件通过 compose 组合成调用链，每层都可以处理当前 action，再用 next(action) 交给下一层。以 redux-thunk 为例，遇到函数类型的 action 就执行它并传入 dispatch、getState，普通对象则直接放行。这个机制类似面向切面编程：核心状态流不用改动，扩展逻辑集中挂在派发边界，但中间件顺序会影响实际执行顺序。

这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。

版本校准： 本文若分析 ReactDOM.render、旧生命周期或栈调和，应把它视为理解架构演进的历史路径。React 19 已移除 ReactDOM.render，当前客户端入口使用 createRoot；并发渲染也必须区分可中断的渲染阶段与同步提交阶段。迁移前对照 React 19 官方升级指南。

# 认识 Redux 中间件

中间件相关的信息将作为 createStore 函数的一个 function 类型的入参被传入。这里我们简单复习一下 createStore 的调用规则，示例代码如下：

# 中间件的引入

// 引入 redux
import { createStore, applyMiddleware } from 'redux'
......
// 创建 store
const store = createStore(
    reducer,
    initial_state,
    applyMiddleware(middleware1, middleware2, ...)
);